A significant problem facing the Internet community is that on-line businesses and organizations are vulnerable to malicious attacks. Recently, attacks have been committed using a wide arsenal of attack techniques and tools targeting both the information maintained by the on-line businesses and their IT infrastructure. Hackers and attackers are constantly trying to improve their attacks to cause irrecoverable damage, overcome current deployed protection mechanisms, and so on.
For example, recently identified attacks were committed through cryptographic protocols including, but not limited to, transport layer security (TLS), secure socket layer (SSL), and the like. A prime example for such attacks is the encrypted denial-of service (DoS) or encrypted distributed DoS (DDoS) attacks. A DoS/DDoS attack is an attempt to make a computer or network resource unavailable. A common technique for executing DoS/DDoS attacks includes saturating a target computer with external requests. As a result, the target computer becomes overloaded, thus it cannot respond properly to legitimate traffic. When the attacker sends many packets of information and requests to a single network adapter, each computer in the network would experience effects from the DoS attack. A DDoS attack is performed by controlling a large number of machines and directing them to attack as a group. Various techniques for mitigating non-encrypted DoS and DDOS attacks are discussed in the related art.
The encrypted DoS/DDoS are performed against servers having an encrypted connection with their clients. That is, the communication protocols utilized between servers and clients may include TLS, SSL, and the like. Encrypted DoS/DDoS attacks cannot be detected and mitigated by mere use of the conventional techniques for mitigating non-encrypted DoS/DDoS attacks. Specifically, current detection techniques typically are not adapted to decrypt the encrypted traffic, and encrypted Dos/DDoS attacks simply pass “under the radar” of existing security solutions.
The disability to detect and mitigate encrypted Dos/DDoS attacks significantly impacts online businesses that use cryptographic protocols. Such attacks greatly exploit the computing resources because encrypted traffic requires more resources for processing. For example, decryption of encrypted traffic consumes more CPU resources than processing of a non-encrypted traffic. Thus, even a “small scale” encrypted DoS attack can cause a targeted server to become unresponsive.
There are a number of conventional solutions that provided limited capabilities in detecting and mitigating threats of different types of attacks not including DoS/DDoS attacks performed through SSL protocols. Such solutions require processing of both ingress (from clients) and egress (from servers) traffic in order to detect and mitigate such attacks. For example, as a shown in FIG. 1A, an encrypted connection (e.g., a SSL connection) 101 is established between a client 110 and a server 120 and the traffic flows between them is copied to a decryption engine 130. The engine 130 is typically connected to a copy/span port of the network, thus traffic from both directions, i.e., egress traffic 102 and ingress traffic 103 are copied to the engine 130.
The decryption engine 130 decrypts the traffic using the encryption keys utilized by the client 110 and the server 120. Then, the decrypted traffic is processed to detect malicious threats in the traffic. One of the limitations of these solutions is that the decryption engine 130 must receive both the egress and ingress traffic direction in order to perform the decryption and to detect attacks, as the engine 130 must receive the encryption parameters of both the server and client. For example, in a SSL handshake, the server typically responds with a server “hello” message that contains the cryptographic method (cipher suite), the data compression method selected by the server, the session ID, and another random number.
Another conventional solution for mitigating encrypted (e.g., SSL) attacks is depicted in FIG. 1B. Here, a termination engine 140 is connected in-line with the traffic between the client 110 and the server 120. The termination engine 140 maintains the encrypted connections with the client 110 and server 120. With this aim, the termination engine 140 receives and processes the server's 120 replies in order to establish and maintain a server side TCP connection. In case the server side connection is required to be encrypted as well (e.g., SSL) then engine 140 receives the outbound traffic with the server's cryptographic parameters mentioned above.
As can be understood from the above discussion, the conventional solutions require an active connection with the server 120 and to receive traffic from the server in order to enable communication between the client and the server. Thus, the conventional encrypted attack detection solutions cannot be applied in secured datacenters that process only inbound (ingress) traffic. Typically, in such secured datacenters, when an attack is detected, only the inbound traffic is diverted through the attack mitigation device. As a result, the attack mitigation solution cannot decrypt the encrypted client-server traffic. This is due to the fact that the decryption engine 130 must receive cryptographic parameters that are provided in the outbound traffic and the termination engine 140 can establish a TCP connection with the server only if it receives the server's replies (i.e., process out bound traffic). In addition, cryptographic parameters are provided in the outbound traffic and require fully symmetric traffic (e.g., as part of the SSL handshake process). Furthermore, the conventional encrypted attack detection solutions are not adapted to detect Dos/DDoS encrypted attacks.
It would be, therefore, advantageous to provide an efficient security solution for detecting and mitigating attacks of encrypted DoS and/or DDoS attacks. It would be further advantageous if the proposed security solution would mitigate such attacks in a secured datacenter that processes only inbound traffic.